Universal client engine for a client-server environment

ABSTRACT

A system, and associated methods, for generating a user interface with respect to a server are provided. The system includes a client engine, which is connected by a real or virtual connection to an interface repository, an object interface module, a server interface module, and a user interface device. The client engine has the capability to transmit a request for an object reference to the object interface module, and to receive an object reference from the object interface module. The client engine also has the capability to request object type definition data from the interface repository based on the object reference and to receive the object type definition data from the interface repository. A user may then invoke a selected method on the server and receive a response generated by the server. The client engine can generate a display on a user interface connected to the client engine based on the object type definition data.

CLAIM OF PRIORITY

The instant patent application claims priority from (a) the U.S.provisional patent application Ser. No. 60/060,107, "CellularCommunication System," naming Anthony G. Fletcher and Scott D. Hoffpauiras inventors, filed on Sep. 26, 1997; and (b) the U.S. provisionalpatent application Ser. No. 60/071,145 filed Jan. 12, 1998, "System andMethod for Generating Server Interface," naming Jaroslaw Wilkiewicz asinventor, filed on Jan. 12, 1998.

RELATED PATENT APPLICATIONS

The instant patent application is related to the following patentapplications: (a) U.S. patent application No. 08/678,254, now U.S. Pat.No. 5,835,486 entitled "Multi-Channel Transcoder Rate Adapter Having LowDelay and Integral Echo Cancellation," naming James M. Davis and JamesD. Pruett as inventors, filed Jul. 11, 1996; and (b) the U.S. patentapplication Ser. No. 09/025,870 entitled "Integrated TelecommunicationsSystem," DSC Case No. 834-00, atty. docket no. 24194000.180, namingAnthony G. Fletcher and Scott D. Hoffpauir as inventors, commonly ownedand assigned with the present application and filed contemporaneouslywith this application.

FIELD OF THE INVENTION

The present invention relates generally to switching systems fortelecommunications, and more particularly to a client engine for thegeneration of a client in a client-server environment.

BACKGROUND

Switching systems are used to provide telecommunications servicesbetween multiple user interfaces. Switching systems typically usemultiple processors to control the operation of various switching systemcomponents. A system architecture that accommodates and coordinatesoperations between two or more processors typically includes one or moreserver-client relationships, in which one or more processors operate asclient while one or more other processors operate as servers. Aclient-server relationship may be utilized to improve the operatingspeed and reliability of the multi-processor system.

Although client-server relationships are useful, a client is oftenrequired to test the server, set-up or configure the server, or use theserver from a client or remote terminal. A different client program istypically written to test each server, which results in a cost ofperson-hours of effort to produce code that will only be briefly used.If a client is required to set-up or use the server, then one or moresuch client programs must be maintained for each server. If a largenumber of servers are utilized in a given system, then a correspondinglarge amount of file space must be used to store the client programs. Inaddition, a significant number of person-hours of effort will berequired in order to coordinate the client programs to make themuniform, and to maintain the client programs.

SUMMARY OF THE INVENTION

Therefore, a need has arisen for a system and method for generating aclient that does not require a unique client program to be written,stored, and maintained for each server. In accordance with the presentinvention, a system and method for a client engine that generatesclients for interfacing with a server are provided that substantiallyeliminate or reduce disadvantages and problems associated withpreviously developed systems and methods for interfacing with a server.

One aspect of the present invention is a system for generating a userinterface. The system includes a client engine, which is connected by areal or virtual connection to an interface repository, an objectinterface module, a server interface module, and a user interfacedevice. The client engine has the capability to transmit a request foran object reference to the object interface module, and to receive anobject reference from the object interface module. The client enginealso has the capability to request object type definition data from theinterface repository based on the object reference and to receive theobject type definition data from the interface repository. The clientengine can generate a display on a user interface connected to theclient engine based on the object type definition data.

Another aspect of the present invention is a method for generating auser interface. The method includes causing transmission of an objectmarker to a server from a client engine system. An object reference isthen received from the server at the client engine system. An interfacedescription request is then transmitted from the client engine system toan interface repository, and interface description data is received fromthe interface repository at the client engine system. A display is thengenerated based on the interface description data.

Yet another aspect of the present invention is a method for generating auser interface. The method includes requesting object marker data with aclient engine. The object marker data is then transmitted to a server.An object reference is then received from a server at the client engine.Interface data is then requested from an interface repository using theobject reference. The interface data is received from the interfacerepository at the client engine. A data prompt is then generatedcontaining the interface data.

The present invention provides many important technical advantages. Oneimportant technical advantage of the present invention is a system forgenerating a user interface that does not require a unique clientprogram to be written for each server. The system for generating a userinterface of the present invention thus eliminates the need to spendproductive time creating programs that will only be briefly used to testa server that will not subsequently require an interface program.Another important technical advantage of the present invention is amethod for generating a user interface that may be used to provide aclient for use with one or more servers. The method for generating aclient of the present invention thus allows a single client engine to beused to provide a user interface to servers for testing, set-up, or useinstead of requiring unique programs for each server and for eachapplication.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention and theadvantages thereof, reference is now made to the following descriptiontaken in conjunction with the accompanying drawings, wherein likereference numerals represent like parts, in which:

FIG. 1 is a block diagram illustrating a client engine system, inaccordance with an exemplary embodiment of the present invention;

FIGS. 2A and 2B are a flow chart illustrating a method for a clientengine system, in accordance with an exemplary embodiment of the presentinvention;

FIG. 3 is a block diagram illustrating a telecommunications network, inaccordance with an exemplary embodiment of the present invention; and

FIG. 4 is a block diagram illustrating a telecommunications switch, inaccordance with an exemplary embodiment of the present invention.

DETAILED DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a universal client engine system 82 and associatedelements for interfacing with a server in accordance with an exemplaryembodiment of the present invention. Such client engine system 82 may beused to interface with a server 86 for developmental and/or operationalpurposes, and does not require server-specific programming.

The client engine system 82 may be implemented in software, hardware ora suitable combination of software and hardware. For example, the clientengine system 82 may be a software system that operates on a suitableplatform, such as a personal computer, a work station, a lap topcomputer or other suitable hardware platforms. The client engine system82 may operate on, and be connected to, a terminal 454 of atelecommunications switch 312. The client engine system 82 is preferablyconnected to a server 86 and an interface repository 88, which containsdata that defines the operations, arguments and output formats forpredetermined servers. The connections between the client engine system82 and other components, and between the elements of the client enginesystem 82, may be either real, such as with conductors or other physicalmedia, or virtual, such as by logical components of a computingplatform.

The client engine system 82 is operable to receive object data from auser via a user interface device 90, and to transmit the object typedata to an interface repository 88. The client engine system 82 thenqueries the user via the user interface device 90 to provide argumentdata for submission to a server 86. After the user enters the argumentdata, the client engine system 82 converts the user-entered argumentdata into the format required by the server 86. The client engine system82 then transmits the formatted argument data to the server 86, andreceives the data generated by the server 86 in response to the argumentdata. The data is then converted into the proper output format fordisplay on the user interface device 90.

The client engine system 82 preferably further includes a client engine84, an object interface module 92 and a server interface module 94. Theclient engine 84 is preferably connected an object interface module 92,a server interface module 94, a server 86, an interface repository 88and the user interface device 90. The client engine 84 may beimplemented in software, hardware, or a suitable combination of softwareand hardware. The client engine 84 is operable to query the server withargument data, and may be configured to use an object interface module92 such as an Orbix™ Common Object Request Broker Architecture "string₋₋to₋₋ object" function. The client engine 84 may also be configured touse a server interface module 94 such as an Orbix™ Common Object RequestBroker Architecture "Request" class and a Dynamic Invocation Interface.

The object interface module 92 may be implemented in software, hardwareor a suitable combination of software and hardware. The object interfacemodule 92 is operable to receive object data from the client engine 84,such as host name data, server name data and object marker data, toquery a server for object reference data, and to return an objectreference from a server if the object defined by the object data exists.If no object exists, the server 86 generates an error code and theobject interface module 92 returns an error message.

The server interface module 94 may be implemented in software, hardwareor a suitable combination of software and hardware. The server interfacemodule 94 is operable to receive argument data and to transmit theargument data to a server 86. The server interface module 94 istypically not required for interfacing the data generated by the server86 in response to the argument data back to the client engine 84.

An interface repository 88 may be implemented in software, hardware or asuitable combination of software and hardware. An interface repository88 may be distributed or centralized, and typically maintains data thatdefines the operations, arguments and output formats for predeterminedobjects of predetermined servers.

A server 86 may be implemented in software, hardware or a suitablecombination of software and hardware. A server 86 typically comprises asoftware application operating on a suitable hardware platform. Forexample, the server 86 may be a server operating on a network managementserver 50 of the telecommunications switch 312. The server 86 isoperable to receive data from a client, to perform data processingfunctions responsive to that data, and to generate predeterminedresponses to the data for transmission back to the client or to othersystems or devices. For example, the server 86 may receive object markerdata from the object interface module 92, return object reference dataif the object is known to the server 86, and return an error if theobject is not known to the server 86. Likewise, the server 86 mayreceive argument data from a server interface module 94, and generatedata in response to the argument data.

A user interface device 90 is preferably suitable to transmit andreceive data with respect to the client engine system 82 and to generatea user interface. For example, a user interface device 90 may be aterminal 454 of a telecommunications switch 312. A user interface device90 may also, for example, be a laptop computer, desktop computer, aremote terminal, a workstation or other suitable user interfaces. Theuser interface system 90 is operable to receive data from a user, and togenerate graphical and textual data that may be interpreted by the user.

In typical operation, a client engine system 82 is provided to allow auser to interface with a server 86. The server 86 may be a test serverthat is being developed for use, or may also or alternatively be anexisting server that is in use or operation. A user initiates the clientengine system 82, which prompts the user for object marker data. Afterthe user enters the object marker data, the client engine sysetem 82obtains data that describes the operations, arguments, and output dataformats pertaining to the object from an interface repository 88. Theuser enters argument data for submission to the server and transmits thedata to the server 86. The server response data is received by theclient engine system 82 and is converted into a user-readable format. Inthis manner, the use may test or interface with a server 86 without theneed for design and storage of server-specific interface software.

Although the client engine system 82 has been described in context of atelecommunications switch operating environment, it may be readilyappreciated that the client engine system 82 may be employed in thecontext of other operating environments utilizing a client-serverarchitecture. For example, a client engine system 82 may be employed ina computer network, such as a local area network or wide area network, acomputer control network for controlling manufacturing or plantoperations or other suitable network environments.

FIGS. 2A and 2B illustrate a method 100 associated with the clientengine system 82 in accordance with one embodiment of the presentinvention. Such method 100 may be implemented in software, hardware, ora suitable combination of hardware and software on a suitable platform,such as terminal 454 of FIG. 4.

Such method 100 begins at step 102, where the client engine prompts theuser for the host name, server name, and marker name of an object. Othersuitable data may also or alternatively be prompted from the user. Themethod then proceeds to step 104, where the user enters the requesteddata. At step 106, the client engine invokes an object interface module,such as a "string₁₃ to₋₋ object" method, which is used to verify thatthe object exists within the remote server.

At step 108, it is determined whether the object has been found. If theobject has not been found, the method proceeds to step 110, where anerror is returned and an error message is generated.

If the object has been found, the method proceeds to step 112, where anobject reference is returned to the client engine. At step 114, theclient engine then transmits the interface type for the object referenceto an interface repository that holds interface information forpredetermined servers. The method then proceeds to step 116, where it isdetermined whether a client engine expansion has been installed.

The client engine expansion is a memory cache that allows the clientengine to receive all of the interface data pertaining to apredetermined interface from the interface repository and to display itto the user in a suitable format. If the client engine expansion has notbeen installed, the method proceeds to step 118. At step 118, theinterface repository transmits a list of all operations for thetransmitted object reference to the client engine.

At step 120, the client engine prompts the user to select an operation,such as by listing all available operations and allowing the user toselect one or more of the operations. The user enters a selection atstep 122, and the method proceeds to step 124 where the client enginetransmits the operation to the interface repository.

At step 126, the interface repository transmits all of the argumentdescription (such as type and name) for the operation to the clientengine. The client engine then prompts the user for input values for thearguments at step 128. The user-entered inputs are converted into aproper data type and data format at step 130. For example, the user mayenter various fields that may require conversion into a specified datastructure.

After the arguments are assembled by the client engine, the methodproceeds to step 132 where a server interface module is used, such as a"Request" class. The server interface module receives the assembledarguments at step 132, and transmits the assembled argument data to theserver at step 134. The server receives the arguments and generates aresponse in accordance with the server programming at step 136.

At step 138, the response is received at the client engine. The clientengine requests the output data format for the response from theinterface repository at step 140, and the interface repository transmitsthe output data format to the client engine at step 142. The method thenproceeds to step 162.

If the client engine expansion has been installed, the method proceedsfrom step 116 to step 144. Steps 144 through 160 are similar to steps118 through 142, with the difference being that all interfacedescription data pertaining to the operations, arguments, and outputformats that are associated with the object reference are transmitted tothe client engine from the interface repository at step 144. Thisprocess eliminates the need to request additional data from theinterface repository, such as at steps 124 and 140. Because the data isprovided before a decision is made by the user regarding what data isrequired, the client engine expansion is required to process and storethe additional data until it is required for use.

At step 146, the client engine prompts the user to select an operation,such as by listing all available operations and allowing the user toselect one or more of the operations. The user enters a selection atstep 148, and the method proceeds to step 150 where the client engineprompts the user for input values for the arguments.

The user-entered inputs are converted into a proper data type and dataformat at step 152. For example, the user may enter various fields thatmay require conversion into a specified data structure. After thearguments are assembled by the client engine, the method proceeds tostep 154 where a server interface module is invoked using a "Request"class. The server interface module receives the assembled arguments atstep 154, and transmits the assembled argument data to the server atstep 156. The server receives the arguments and generates a response inaccordance with the server programming at step 158.

At step 160, the response is received at the client engine. The methodthen proceeds to step 162, where the client engine generates output datain the output format provided by the interface repository. For example,the data generated by the server is typically an undifferentiated streamof data that must be converted into a user-readable form. The clientengine converts the generated output data into a user-readable form atstep 164, such as by generating a graphic user interface or text userinterface that contains text and/or graphics.

In operation, method 100 is implemented by a user to interface with aserver. Method 100 may be used to test a server that is being developedto determine whether the server is performing the desired functions.Likewise, method 100 may be used to query an operational server toperform operational or diagnostic work with the server. Method 100 maybe used to interface with two or more servers instead of using softwarethat has been written for each server.

FIG. 3 illustrates a telecommunications network 310 embodying conceptsof the present invention. The telecommunications network 310 is ageneral telecommunications system that may be used to providetelecommunications services to users, without requiring the users toaccess land based telecommunications interfaces, such as telephonehandsets. Telecommunications network 310 may be a Public Land MobileNetwork (PLMN).

The telecommunications network 310 includes one or moretelecommunications systems or switches 312. A telecommunications system312 is a self-contained telecommunications system, and may be coupled toanother telecommunications switch 312. A telecommunications switch 312is typically coupled to a switched network 314, such as the PublicSwitched Telephone Network.

A telecommunications switch 312 may be coupled to one or more basetransceiver stations 316, and may be configured to control the operationof any base transceiver station 316 coupled to the telecommunicationsswitch 312. A base transceiver station 316 is used to control wirelesstelecommunications traffic in a service area or cell 320. Subscriberunits 322 are used in conjunction with the base transceiver stations 316and the telecommunications switches 312 to communicate with othersubscriber units 322 or with the switched network 314.

The telecommunications switch 312 may be coupled to othertelecommunications switches 312, the switched network 314 and to basetransceiver stations 316 by a suitable transmission link 24, such as anE1 telecommunications line. Similarly, a base transceiver station 316may be coupled to another base transceiver station 316 by a suitabletransmission link 26. An E1 telecommunications line carries 2.0448megabits of data per second in a standard data format. This standarddata format is organized as 30 digitally-encoded telecommunicationschannels carrying 64,000 bits per second for voice or data applications.In addition, the standard data format includes a single 64,000 bit persecond data channel for signaling data, and a single 64,000 bit persecond channel for framing, synchronization, maintenance, and controlpurposes. The base transceiver stations 316 may also transfer data tothe telecommunications switches 312 in a Link Access Protocol on the DChannel (LAP-D) data format.

In operation, a user attempts to establish a telecommunication channelusing a subscriber unit 322. The user, located in a cell 320, activatesa subscriber unit 322, which transmits a service request to a basetransceiver station 316 using radio frequency electromagnetic radiation.This radio frequency electromagnetic radiation includes encoded data ina suitable data transmission format, such as, for example, time divisionmultiple access or code division multiple access. Once received, thebase transceiver station 316 transmits the service request to thetelecommunications switch 312. The telecommunications switch 312 thendetermines the destination identified by the service request andestablishes a telecommunications channel with that destination.

For example, if the destination is another subscriber unit 322 that isserviced by the telecommunications switch 312 processing the servicerequest, the telecommunications switch 312 will transmit control andsignaling data to the appropriate base transceiver station 316. Thiscontrol and signaling data will be used to notify the user of thesubscriber unit 322 that an incoming call is being attempted.Alternatively, the telecommunications switch 312 may transmit controland signaling data to another telecommunications switch 312, which willthen transmit appropriate control and signaling data to a basetransceiver station 316 for communication with a subscriber unit 322serviced by that other telecommunications switch 312.

If the user at the subscriber unit 322 transmits a request for servicethat identifies a destination associated with a switched network 314,the telecommunications switch 312 will transmit appropriate signalingand control data to the switched network 314. In addition, thetelecommunications switch 312 will receive signaling and control datafrom the switched network 314 that indicates whether atelecommunications channel has been successfully established with theidentified destination. After a telecommunications channel isestablished, the telecommunications switch 312 performs operation,administration, maintenance and provisioning functions to maintain thetelecommunications channel until the call is completed. Once completed,the telecommunications switch 312 de-allocates the call resources.

FIG. 4 illustrates a telecommunications switch 312. Thetelecommunications switch 312 includes multiple resource modules 441that provide other elements and components of the telecommunicationsswitch 312 with suitable resources, such as, for example, switching,rate adaption and transcoding functions. In accordance with an exemplaryembodiment, one or more switching modules 4442, interface modules 446,telephony support modules 444 and signal processing modules 448 areprovided within a resource assembly 441. The interface modules 446,signal processing modules 448 and telephony support modules 444 arecoupled through one or more of the switching modules 4442. Controlinformation is provided by a switching module 4442 to other modules overthe redundant control bus 64. Data is provided by a switching module4442 to other modules over a high speed bus 65.

A switching module 4442 may be implemented in software, hardware or asuitable combination of software and hardware. A switching module 4442preferably performs switching operations, clock operations, and localcommunications between resources of the resource assembly 441 of thetelecommunications system 312. These operations may be performed usingpulse code modulation switching and data transfer techniques, LinkAccess Protocol on the D Channel (LAP-D) communications and Ethernetinterface communications. The switching module 4442 may include one ormore server or client systems that facilitate the operation of switchingmodule 4442.

A switch 43 preferably resides within a switching module 4442 to performthe switching functions and operations. That switch 43 may be a timeslotswitch having a memory timeslot matrix to make required timeslotcross-connections within the telecommunications system 312. The switch43 functions to set up and tear down both simplex and duplex connectionsbetween two specified channels, which may represent a call or otheruseful connections. For example, the switch 43 may cause a channel toconnect a channel (provided by, for example, a base transceiver station316 or a switched network 314) to a call progress tone or a voiceannouncement. Further, the switch 43 should be operable to set up systemdefined connections upon power up and reset as well as connections forthe testing of timeslots when not in use. Timeslots are preferablyprovided to the timeslot switch via the high speed bus 65.

A switching module 4442 may also, for example, include suitable digitaldata processing devices, a processor, random access memory and otherdevices. Preferably, each switching module 4442 runs a suitableoperating system, and include one or more pulse code modulation businterfaces, one or more High Level Data Link Controller (HDLC) controlbus interfaces, one or more Ethernet interfaces, and an arbitration businterface to other switching modules 4442.

A telephony support module 444 may be implemented in software, hardwareor a suitable combination of software and hardware. A telephony supportmodule 444 may, for example, provide tone generation, R2 digittransceiver functions, and digitized announcement generation for thetelecommunications system 312. Telephony support modules 444 may alsoprovide call setup functions, such as digit collection and out-pulsing,and call completion functions, such as digitized announcement generationand call supervisory tone generation. A telephony support module 444may, for example, include suitable telecommunications data processingequipment, such as a processor, random access memory, one or moreredundant High Level Data Link Controller bus interfaces, one or morepulse code modulation buses, and an arbitration bus for establishingactive telephony support module 444 status. Preferably, a singletelephony support module 444 provides all required functionality for thetelecommunications system 312, and one or more additional telephonysupport modules 444 are used to provide redundancy in the event ofcomponent failure. The telephony support module 444 may include one ormore server or client systems that facilitate the operation of telephonysupport module 444.

An interface module 446 is an interface device that is used to interfacea suitable number of telecommunications lines that carry data in apredetermined format, such as an E1 data format, with thetelecommunications system 312. Interface modules 446 provide thephysical interface between the telecommunications system 312 and otherequipment, a switched network 314 and base transceiver stations 316.Interface modules 446 also support in-band trunk signaling for DS0 datachannels that are configured for channel associated signaling, andtransmit data to and receive data from a signal processing module 448.An interface module 446 may be implemented in software, hardware or asuitable combination of software and hardware. For example, an interfacemodule 446 may include suitable data processing equipment, such as aprocessor, random access memory, up to four E1 ports, redundant HighLevel Data Link Controller bus interfaces, and pulse code modulation businterfaces. The interface module 446 may include one or more server orclient systems that facilitate the operation of interface module 446.

A signal processing module 448 is preferably used to provide aninterface between a call processor assembly 449 and a signaling system.For example, signaling data may be received from a data transmissionchannel from the switched network 314, and may be switched to anotherdata transmission channel, such as an E1 telecommunications channel,from an interface module 446 to a signal processing module 448 by aswitching module 4442. A signal processing module 448 is also preferablyemployed to perform transcoding and rate adaption functions, such asconverting from a wireless system speech encoding format to a pulse codemodulation data format, as well as other functions, such as echocancellation functions. For example, signal processing modules 448 maybe employed by telecommunications system 312 to convert data from theGSM data format to another format, such as the pulse code modulationdata format. The signal processing module 448 may include one or moreserver or client systems that facilitate the operation of signalprocessing module 448.

An example of a signal processing module 448 that provide transcoding,rate adaption, and echo-cancellation functions, and using an improveddecoding process, is disclosed in U.S. patent application Ser.No.08/678,2454, now U.S. Pat. No. 5,835,486 entitled "Multi-ChannelTranscoder Rate Adapter Having Low Delay and Integral EchoCancellation," naming James M. Davis and James D. Pruett as inventors,filed Jul. 11, 1996, commonly owned and assigned with the presentapplication and which is incorporated by reference herein for allpurposes.

A signal processing module 448 may be implemented in software, hardwareor a suitable combination of software and hardware. In addition to oneore more digital signal processors, a signal processing module 448 mayinclude suitable data processing equipment, such as a processor, randomaccess memory, four daughter board module ports, redundant High LevelData Link Controller bus interfaces, pulse code modulation matrix businterfaces and other signal processing application hardware.

The telephony support modules 444, the interface modules 446, and thesignal processing modules 448 are preferably coupled through switchingmodules 4442 and hub switches 460 to redundant call processor system449. The call processor system 449 is operable to control the functionof components of the telecommunications switch 312.

The call processor system 449 is a general purpose computing platform,such as a PentiumTM II based computing platform, that includes suitablehardware and software systems to support telecommunications processing.The call processor system 449 may use a real-time operating system suchas QNXTM to support the real-time call processing requirements of thetelecommunications switch 312. The call processor system 449 may includeone or more server or client systems that facilitate the operation ofcall processor system 449.

The call processor system 449 preferably includes one or more systemsthat allow it to perform the functions of a base station controllersystem and a message switching center system. In addition, the callprocessor 449 provides other elements that take part in processing callsdirected to, or initiated by, the subscriber units 322. Specifically,the call processor system 449 includes a call processing applicationthat provides various cell processing and signaling functions, such ascall origination and termination functions, as well as location updatingand handover of mobile subscribers.

For example, the call processing application may provide GSM callprocessing functions and include a visitor location register, a homelocation register, a mobile application part, a base station subscriber,a mobile switching center, an SS7 signaling element, and other suitableelements. An example of a GSM call processing application that may beused to provide the functionality of call processor system 449 isdescribed in the U.S. patent application Ser. No. 09/025,870 entitled"Integrated Telecommunications System," DSC Case No. 834-00, atty.docket no. 24194000.180, naming Anthony G. Fletcher and Scott D.Hoffpauir as inventors, commonly owned and assigned with the presentapplication, filed contemporaneously with this application, and which ishereby incorporated by reference for all purposes.

A call processor system 449 may be coupled to a primary and a secondarynetwork management server 50. Primary and secondary network managementservers may be redundant network management systems servers that provideoperation, administration, maintenance and other functions for elementsof the telecommunications switch 312. Network management servers 50,may, for example, incorporate the functionality of both an OperationsMaintenance Center--Radio (OMC-R) and an Operations MaintenanceCenter--Switching (OMC-S).

The network management servers 50 may be implemented in software,hardware, or a suitable combination of hardware and software. Forexample, the network management servers 50 may include software programsin a suitable programming language, such as a commercially availableserver program that includes additional server programs written in C++Java programming languages. Each network management server operates on asuitable hardware platform, such as a PentiumTM II based computingplatform, that includes suitable hardware and software to supporttelecommunications processing. The hardware platform may also oralternatively include other processors such as those embodied in laptopscomputers, desktop computers, workstations, or other suitable devices.The network management servers 50 include server systems that supportthe operation of components of telecommunications system 312. Theseserver systems include, by way of example and not limited to, a basestation controller server, a resource manager server, a messageswitching center server, a signaling system server, a mobile applicationpart server, a visitor location register server, and a home locationregister server.

The signaling interface modules 452 are coupled to the call processors449 and the interface modules 446, and are used to provide an interfacebetween the call processors 449 and a signaling system. For example,data may be received from a transmission link 24, from a switchednetwork 314, or other switches 40, and may be switched to a transmissionlink 24, such as an E1 telecommunications channel, from interfacemodules 446 to signaling interface module 452 by switching modules 4442.

One or more terminals 454 are preferably provided in connection with thetelecommunications system 312. The terminals 454 are coupled to thenetwork management servers 50 either directly or through a modem 456, arouter 458, and hub switch 460. The terminals 454 are used to interfacewith the network management servers 50. The terminals 454 and thenetwork management servers 50 comprise a network management system thatallows a user to remotely monitor and manage a telecommunications switch312.

Terminals 454 include software, hardware or a suitable combination ofsoftware and hardware that allows them to operatively interface with thenetwork management servers 50.

This software may include a client engine system that allows aprogrammer to interface with a functioning server, or test adevelopmental server for implementation on network management servers 50or other components of telecommunications switch 312. The client enginesystem of the present invention does not require an interface program tobe specifically designed for the test server, or any other server.Instead, the generic client for a client-server environment of thepresent invention allows the programmer or a user to interface with anyserver operating on telecommunications switch 312 that may be accessedby terminal 454. The programmer or user may use the client engine systemto design a test server or to interface with an existing server undernormal operations.

In operation, a programmer or user interfaces with a server operating onthe telecommunications switch 312 through a terminal 454. This servermay, for example, be a test server that is under development or testingor an existing server that has been resident on the telecommunicationsswitch 312. A client engine system operating in association with aterminal 454 is therefore needed to allow a user or programmer tointerface with a server.

The client engine system receives object marker data from a user orprogrammer, and obtains the operations, arguments and output dataformats pertinent to the server being tested. The user then submitsarguments to the server through the client engine system, and reviewsthe data generated by the server in response to the submitted arguments,after it has been converted into a user-readable format by the clientengine system. In this manner, server software used intelecommunications switch 312 may be designed and tested withoutrequiring server-specific interface software to be designed, stored andexecuted for each server.

While FIG. 3 and FIG. 4 illustrate a telecommunications switch 312within which the present invention may be employed, it should beappreciated that the present invention may also be employed in numerousother systems and environments within the spirit and scope of thepresent invention.

Although several embodiments of the present invention and its advantageshave been described in detail, it should be understood that changes,substitutions, transformations, modifications, variations, andalterations may be made therein without departing from the teachings ofthe present invention, the spirit and the scope of the invention beingset forth by the appended claims.

What is claimed is:
 1. A system for generating a user interfacecomprising:a client engine connected to an interface repository, anobject interface module, a server interface module and a user interfacedevice; and wherein the client engine is operable to transmit a requestfor object reference to the object interface module, to receive anobject reference from the object interface module, to request objecttype definition data from the interface repository based on the objectreference, to receive the object type definition data from the interfacerepository, and to cause a display on a user interface connected to theclient engine based on the object type definition data.
 2. The system ofclaim 1 further comprising an object interface module connected to aserver that is operable to query the server for object reference data,to receive the object reference data from the server and to cause theobject reference data or an error code to be transmitted to the clientengine.
 3. The method of claim 1 further comprising a server interfacemodule connected to a server is operable to query the server withargument data, and to receive data generated by the server in responseto the argument data, and to cause the server generated data to betransmitted to the service interface engine.
 4. The system of claim 1further comprising an interface repository that is operable to storeserver interface data, including operation data, argument data andoutput format data.
 5. The system of claim 2 further comprising a serverconnected to the object interface module, wherein the server is operableto receive object marker data from the object interface module, toverify that the object is known to the server, and to return an error ifthe object is not known to the server.
 6. The system of claim 3 furthercomprising a server connected to the server interface module, whereinthe server is operable to receive argument data from the serve interfacemodule and to generate data in response to the argument data.
 7. Amethod for generating a user interface comprising:causing transmissionof an object marker to a server from a client engine system; receivingan object reference from the server at the client engine system; causingtransmission of an interface description request from the client enginesystem to an interface repository; receiving interface description datafrom the interface repository at the client engine system; andgenerating a display based on the interface description data.
 8. Themethod of claim 7 wherein transmitting an object marker to a server froma client engine system comprises:prompting a user for one or more ofhost data, server data, and object marker data; causing the host data,server data and object marker data received from a user to betransmitted to the server from the object interface module.
 9. Themethod of claim 7 wherein receiving an object reference from the serverat the client engine system comprises:receiving an error code if anobject reference is not found; and receiving object reference data if anobject reference is found.
 10. The method of claim 7 whereintransmitting an interface description request from the client enginesystem to an interface repository comprises transmitting a request forone or more of operation data, argument data, and output format dataassociated with an object reference to the interface.
 11. The method ofclaim 7 wherein receiving interface description data from the interfacerepository at the client engine system comprises receiving one or moreof operation data, argument data, and output format data from theinterface repository that pertains to an object reference.
 12. Themethod of claim 7 wherein receiving interface description data from theinterface repository at the client engine system comprises:receivingoperation data at the client engine system; prompting a user to selectone or more operations based on the operation data; causing a requestfor argument data to be transmitted from the client engine system to theinterface repository; and receiving argument data pertaining to theoperations at the client engine system.
 13. The method of claim 7wherein generating a display containing the interface description datacomprises:prompting a user to select one or more operations from a listof available operations; prompting the user to enter argument data forarguments pertaining to the selected operations; causing the argumentdata entered by the user to be transmitted to the server; and generatinga display based on the server response to the argument data.
 14. Amethod for generating a user interface comprising:requesting objectmarker data with a client engine; causing trnamission of the objectmarker data to a server; receiving an object reference from a server atthe client engine; requesting interface data from an interfacerepository using the object reference; receiving the interface data fromthe interface repository at the client engine; and, generating a dataprompt containing the interface data.
 15. The method of claim 14 whereinrequesting object marker data with a client engine comprises:generatinga user interface with the client engine that includes a prompt for oneor more of host data, server data, and object marker data; receivingdata at the client engine in response to the prompt; and converting thereceived data into a format that is compatible with a predeterminedserver.
 16. The method of claim 14 wherein causing transmission of theobject marker data to a server comprises:transmission of the objectmarker data to an object interface module from the client engine;causing further transmission of the object marker data to the serverfrom the object interface module; and transmitting an error code ofobject reference data from the server to the client engine.
 17. Themethod of claim 14 wherein generating a data prompt containing theinterface data comprises:generating a data prompt containing a list ofoperations; and receiving a user-entered selection of one or moreoperations from the list of operations.
 18. The method of claim 14further comprising:receiving one or more operations identifiers at theclient engine; prompting the user with the client engine for argumentdata pertaining to the one or more operations identifiers; receiving theargument data at the client engine; and converting the argument datainto a format that is compatible with a predetermined server.
 19. Themethod of claim 18 further comprising:causing transmission of theconverted argument data to a server interface module from the clientengine; causing transmission of the converted argument data to apredetermined server from the server interface module; receivingserver-generated response data at the client engine; and generating adisplay based on the server-generated response data.
 20. The method ofclaim 19 wherein generating a display based on the server-generatedresponse data comprises:converting the server generated response intouser data in accordance with output format data received from theinterface repository; and converting the user data into a user-readableformat.